1. Field of the Invention
The present invention relates generally to the field of storage access in a storage area network (SAN).
More particularly the invention comprises a novel system referred to hereinafter as the Resource Management and Reservation System (“RMRS”) which employs a stand-alone autonomic system for managing, on-line planning of, scheduling and controlling storage access requests.
2. Description of the Prior Art
In the typical application-hosting environment in use today, a storage area network (SAN) service is shared among multiple applications.
For example, application servers are the intermediary between back-end databases and front-end user interfaces. The application servers pull the information requested by a user from the databases, process the data using some business logic and then transmit the processed data to the user interface which then presents it to the user in a human understandable format.
Each application may use a database system, which in turn may access the storage area network service for multiple purposes; such purposes being, for example, access for normal database transactions (i.e., normal on-line transaction processing or “OLTP” workload), backups, recovery, replication and so on. From an application point of view, each type of request has a certain relative priority. Within a sequence of accesses, the types of “requests” are not correlated.
Further, in a hosted environment, the hosting service provider may have multiple grades of service level agreements (hereinafter “SLA”) with customers and the customers may use one or more hosted applications. Thus, a storage access request (e.g., a backup request) from one application may need to be prioritized higher than the similar type of request from another application depending on the customers being served. Storage access requests from two instances of the same application may also need to be differentiated depending on the quality-of-service guarantees given to the customer of each application instance.
Since the current storage service is shared, allocating its bandwidth among different types of accesses from multiple applications requires complex scheduling. Classical approaches used in operating systems or storage subsystems handle this type of complexity by classifying processes or applications into a few manageable classes. Policies are then applied to manage resource contentions and scheduling issues. However, changes in the workload observed in the hosted environment are much more dynamic and traditional approaches tend to be too complex or ineffective or expensive.
Another approach is to manage the complexity from the applications or from the database management systems. However, the commercial off-the-shelf applications or the underlying database management systems are not capable of managing this complexity. The level of customization required to handle die dynamic nature of the hosting environment can be prohibitively expensive. Besides, the business model in hosting environments is providing low cost solutions using economy of scale. Any massive customization effort can defeat the purpose of providing hosted services.
Today, in most instances in storage access requests, actions taken by the RMRS are performed manually by administrators. This approach limits the number of applications that can be managed at a time and limits the extent to which the bandwidth allocation can be optimized.
In summary, in a hosted environment, the business model requires Service Providers (SP) to share the common infrastructure and resources across multiple applications. Storage Area Network (SAN) is used as large shared storage among multiple hosted applications. It is very important for a service provider to optimize the use of (potentially limited) resources across multiple hosted applications depending on their priorities and resource availability. This helps service providers in offering cost-effective solutions to multiple customers. However, it also makes it easier to meet the service level agreements for individual customers in case of resource contentions according to their class of service.
Availability is an important requirement for hosted e-Business applications. Data Recovery, Data Replication are some of the important aspects of application data management which play a key role in governing the high availability requirements of critical customer applications. In many instances, these are “must-provide” kind of services. Data Recovery, Replication services involve heavy storage accesses and so need a good planning to achieve better Quality of Service. We illustrate the use of RMRS service in the context of Data Recovery. Presently Data Recovery is mostly handled manually by system administrators. It involves periodic scheduling of backup tasks and initiation of recovery in case of application crash or data corruption. Existing backup/recovery solutions automate the process up to a certain extent. Traditional centralized backup servers (e.g. IBM Tivoli Storage Manager) try to manage the periodic backups across multiple applications and unexpected recovery jobs with no real time knowledge of the state of utilization of the relevant shared resources like storage bandwidth, network bandwidth etc. This can result in period of high contentions for network and storage bandwidth, followed by periods of underutilization of the available resources. Thus, both starvations as well as low resource utilization are observed repeatedly in the same environment. Further, unplanned overlap of multiple backup and recovery jobs may significantly affect the recovery time objective of the applications.
Application availability is one of the important customer business objectives where data recovery plays a crucial role. Recovery of data from storage subsystems becomes necessary under a variety of conditions, for example, when the on-line data is detected to be corrupt or when an application crashes. There are three types of data recovery schemes:                1. Crash recovery: When an application terminates abnormally and leaves the data source in an inconsistent state, crash recovery becomes necessary. When the application comes back up, it needs to verify the logs and bring back the data source to a consistent point. For example, in case of database, it rolls back all the incomplete transactions at the time of crash. In this case, there is no need of restoring the data from previous backup image. In spite of that, a crash recovery is an I/O intensive operation since it needs to go through the entire active logs to verify consistency and, if required, logs need to be recovered from archives if they are not available locally.        2. Media recovery: When media (e.g., disk drive) fails or corrupts the online application data, then the data needs to be restored on a new media from a copy of the data. For example, in case of databases, if media fails then all the corresponding table spaces need to be restored from the previous backup and then rolled forwarded to the end of the log, to make them consistent with other data in database.        3. Logical Data Recovery: When application itself corrupts the data due to misbehavior or bad application logic, this type of recovery becomes necessary. In such case, it mostly requires the complete data source (database) to be restored from the previous backup image.        
The following are some of the present state of the art commercial solutions, which provide enterprise class backup/recovery services.                1. IBM's Tivoli Storage Manager Data Protection Solution. (http:/www-3.ibm.com/software/tivoli/products/storage-mgr/)        2. SUN Solstice Backup Solution. (http://www.sun.com/storage/software/data_services/backup/)        3. Legato NetWorker Data Protection (http://portal2.legato.com/products/networker/)        4. VERITAS NetBackup Data Protection Solution. (http://www.veritas.com/products/category/ProductCatecgory.jhtml?categryId=2003&baseId=2021)        
Most of these systems are based on the standard client-server architecture where central backup/storage server interacts with multiple backup clients that are designed for individual platforms, applications & data sources (e.g. Tivoli Data Protection clients for SAP R/3/DB2/Oracle on NT/Unix platforms etc.).
IBM's Tivoli Storage Manager's functionality as a representative of existing state of the art solutions is mentioned above. Tivoli Storage Manager (TSM) consists of three main components, TSM Server, TSM Client, and TSM Admin GUI.
TSM Server builds the data management backbone by managing storage hardware, providing secure environment, automating client and admin schedules, providing central management and administration to enterprise client applications through reporting, monitoring and logging of application's data objects inventory in the local database repository.
TSM provides primitive centralized scheduling ability to automate the execution of two types of schedules: 1. Client Schedule consisting of operations such as periodic backup/archive or unexpected recovery. 2. Administrative Schedule consisting administrative tasks that need to run on server e.g. storage pool migration, reporting, and so on. Administrators are required to setup the schedules for backups by specifying the backup command/script, when to execute, how often to run and how long it takes to run the command. It is important to note in the context of current invention that TSM does not consider the fact if command (backup) takes longer than specified time period due to resource contention, which may potentially affect the next scheduled operation that depend on it. TSM Client can either periodically poll with server to get the scheduled start time for its backup/archive events or TSM Server can notify client just before the scheduled start time of the event.
TSM allows application clients to associate with different service classes called policy domains. TSM Server manages multiple policy domains. Application client nodes need to register in a policy domain. Set of operational management policy rules apply to the group of clients in the policy domain. TSM currently uses the policy domains to group the clients according to their operational management requirements. It does not associate any Quality of Service policies to prioritize or differentiate the clients based on their Service Level Agreements.
TSM Client along with application specific extensions (e.g. Tivoli Data Protection for SAP R/3) executes the backup/recovery tasks on the application nodes as per the defined schedule. Web based GUI allows remote administration and setup of TSM Client and Server.
TSM optional software extension (presently: http://www-3.ibm.com/software/tivoli/products/storage-mgr-san/) allows SAN-connected computers to use the SAN for data protection data movements. So the bulk of the data transfer for backups or archives can either be done directly to TSM Server (over LAN) and which in turn stores the data on the offline storage or data can be directly transferred to storage devices over the Storage Area Network (SAN) without impacting Local Area Network (LAN) and CPU utilization on the application hosts.
Optional software extension for Hierarchical Space Management (HSM) (presently: http://www-3.ibm.com/software/tivoli/products/storage-mgr-space/) allows TSM Client to periodically move application's inactive data to less-expensive offline storage or near-line storage (over LAN or SAN), freeing online disk space for more important active data. We see an important need for generating the efficient resource optimal schedule for such periodic data movements as well.
In summary, the existing solutions simplify, centralize, and automate data protection for multiple enterprise applications across various heterogeneous platforms and data sources. They provide tools for database administrators (DBA) that help manage the backup and recovery tasks. However, none or these solutions are intelligent or autonomic in terms of generating efficient schedules for backup/recovery for optimizing the storage accesses in a central consolidated (like SAN) storage environment which proves useful for both applications as well as service providers. Further, we are not aware of any other system that can manage the backup and recovery tasks across multiple hosted applications in an autonomic manner by adapting to the changes in resource usage demands In addition, the existing solutions do not provide assistance in aggregated capacity planning, reservation and scheduling of network and storage resources. In a hosted environment, where the infrastructure is shared, demand aggregation over the entire suite of backup/recovery tasks is important. However, existing solutions do have the capabilities to handle the required aggregation for capacity planning. This is an important need identified in the vision of vendor neutral “Shared Storage Model” put forth by Storage Networking Industry Association (SNIA presently at: www.snia.org). RMRS consolidates this important requirement and provides that as a service to backup/recovery systems mentioned above, which presently focuses mainly on automating the backup/recovery process.
Though it is clear that a system such as the one described in this invention is essential for managing various types of storage accesses, for the sake of illustration we focus on backup/recovery type of data accesses. Also here after, in this document, TSM and other similar centralized control servers, which manage the application data transfers for Data Protection are referred to as “Application Data Recovery Servers (ADRS).”
For intelligent scheduling of the backup and recovery tasks on the storage subsystems, ADRS interacts with RMRS, which is a centralized web based system for managing the storage accesses across multiple I/O intensive backup & recovery tasks. Normally backups are relatively low priority tasks and periodic in nature and hence very well suited for advance resource reservation. Recovery tasks are high priority tasks and mostly unpredictable in nature and require immediate allocation of bandwidth and storage resources. ADRS assigns unique priorities to tasks based on the task types (backup, recovery etc.) and applications and customers associated with the I/O tasks (depending oil the policy domain to which customer/application is associated with). ADRS and RMRS together achieve the level of automation needed to manage the storage requirements of a large-scale hosted environment.
One of the objectives of ADRS is to provide reservation and capacity planning tools to Service Providers. Service Providers need such tools in provisioning and pricing purposes. The reservation and planning tools are needed to regulate and optimize the storage accesses for I/O intensive tasks like backup/recovery/OLTP workloads across multiple hosted applications and avoid the need for over resource provisioning.
The instant invention provides the means to achieve the objective mentioned above. The system (RMRS) described in the current invention does the advance reservation and priority based scheduling of the storage bandwidth across multiple application's I/O intensive tasks like backup and recovery. As described in detail in the embodiment section hereinafter, RMRS exposes a well-defined client interface for the systems such as ADRS. Using this interface, ADRS negotiates the storage bandwidth allocation with RMRS, on behalf of the applications it manages. ADRS registers with RMRS the I/O tasks such as backup/recovery for each application, along with other attributes such as the task priority, expected storage bandwidth, task frequency and so on. ADRS then requests RMRS to generate an optimal schedule for periodic tasks like backups or requests immediate scheduling for high priority tasks such as a recovery task. RMRS keeps track of the storage bandwidth utilization across multiple applications and effectively schedules the bandwidth across the backup/recovery tasks in their specified time constraint windows while minimizing the contention for the bandwidth resource. Since RMRS manages the bandwidth utilization taking into account the demands from the entire set of applications, it has the ability to advise the ADRS on additional bandwidth provisioning required whenever a new customer is signed on or when a new application task is registered. Thus, RMRS is an important complementary component of ADRS, helping ADRS to achieve the customer's business objectives as well as helping service providers in optimizing their resource usage.
In another possible scenario, as opposed to the one described above where central control server (like ADRS) talks to RMRS on behalf of managed client applications, the client applications can directly interact with RMRS using RMRS client interface Legacy applications which can not change their application logic can talk to RMRS through the representative agents like TSM backup/archive clients to effectively schedule the backup recovery jobs in a shared hosted or enterprise network environment. Applications can specify the required parameters like backup frequency, expected storage bandwidth (based on expected runtime and data size), priority and time constraint windows in which backup should (or should not) be scheduled. Applications can obtain their relative priorities based on their associated policy domain or management class corresponding to their Service Level Agreements with service provider. (RMRS can potentially operate without relative application priorities where it can play a role more in maximizing the usage of storage bandwidth across multiple application requests.)
In the absence of the services provided by RMRS, ADRS would lack in the crucial functionality of priority based resource reservation and scheduling for backup/recovery tasks which are I/O intensive data movement tasks.
It would be difficult for ADRS to provide quality of service guarantees on the application recovery time objective as well as on the OLTP performance. The OLTP performance may very well be affected by periodic backup jobs. Provisioning of excessive network/storage bandwidth may eliminate the need of RMRS, but that would be an expensive solution for a service provider and also it does not support an emerging trend of Business on Demand in service oriented architecture e.g. IBM's business on Demand initiative (presently: http://www-1.ibm.com/service/ondemand/index_flash.html).
To provide the resource reservation and task scheduling and planning services, RMRS makes use of a scheduling component. As described in the embodiment, this component models the problem as an optimization problem and produces optimum or near optimal solutions that meet the defined objectives.
A large body of work exists in the literature that addresses the problems associated with resource scheduling and planning. In particular, in recent years much work has been done in the context of grid computing that is relevant to the planning and scheduling problem addressed by RMRS. [For an overview of grid computing, see “The Anatomy of the Grid: Enabling Scalable Virtual Organizations,” I. Foster, C. Kesselman, S. Tuecke. International J. Supercomputer Applications, 15(3), 2001, the contents of which are hereby incorporated by reference herein. Presently available at http://www.globus.org/research/papers/anatomy.pdf]
As grid concepts revolve around the resource sharing and collaborative computing using widely distributed heterogeneous, independently administered resources, where the distributed resource management becomes a key requirement.
Scheduling with Advance Reservation and co-Allocation of resources help achieve end to end Quality of Service (QoS) for grid applications. [See: “Globus Architecture for Reservation and co-Allocation (GARA)] A Distributed Resource Management Architecture that Supports Advance Reservations and Co-Allocation,” I. Foster, C. Kesselman, C. Lee, K. Lindell, K. Nahrstedt, A. Roy. Intl Workshop on Quality of Service, 1999, the contents of winch are hereby incorporated by reference herein. (presently available at http://www.globus.org/documentation/incoming/iwqos.pdf). This disclosure proposes the uniform framework that enables the construction of an application level co-reservation and co-allocation libraries that applications can use to dynamically assemble collections of heterogeneous resources, guided by application's quality of service requirements and local administration policies of individual resources. An end-to-end Bandwidth Reservation in IP networks using central bandwidth broker and a set of cooperating resource managers is described in QoS as Middleware: Bandwidth Reservation System Design,” G. Hoo, W. Johnston, I. Foster, A. Roy, Proceedings of the 8th IEEE Symposium on High Performance Distributed Computing, pp. 345-346, 1999, (available at http:/www.globus.org/documentation/incoming/hoo.pdf), the contents of which are hereby incorporated by reference herein.
The schemes mentioned above and in most other grid related literature require co-allocation and co-scheduling of resources. This means multiple resources are reserved for simultaneous use by the grid applications. This implies synchronization among the resources and their use in a batch mode. Many types of resources and many types of applications benefit from the approaches described in the above referenced articles. However, in the context of storage subsystems, which are of prime concern to RMRS, effective and systematic time-sharing of a storage resource is a key for achieving high utilization and for avoiding hot spots caused by contention for bandwidth. Explicit synchronization among storage resources is not desirable for the storage access patterns and the types of applications managed by ADRS. In this important aspect, the approach taken by RMRS differs from the grid resource allocation work.
Many of the scientific and commercial grid applications require an efficient access to very large data sets in the range of tera/peta bytes. Data Grid addresses this problem by enabling the storage consolidation across widely distributed and independently managed heterogeneous storage systems (e.g. RAID Servers, SAN, NAS based file systems etc.) and providing core infrastructure services to manage the metadata and data (e.g., Metadata catalog service, data replication service, replica location service and so on).
The focus of RMRS in the current invention is more on resource management for network based storage (such as SAN) in terms of dynamic discovery, reservation and allocation of storage resources. RMRS on behalf of one or more Storage Servers exposes this ability using standard Web Service Interface. It essentially enables individual Storage Server(s) or subsystems to participate in a GARA like distributed reservation and co-allocation framework and also make them compliant for Open Grid Services Architecture (OGSA). This open grid services architecture is described in The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, I. Foster, C. Kesselman, J. Nick, S. Tuecke, Open Grid service Infrastructure WG, Global Grid Forum, Jun. 22, 2002, (presently available at http://www.globus.org/research/papers/ogsa.pdf), the contents of which are hereby incorporated by reference herein.
In addition to planning and scheduling I/O requests, the instant invention also describes managing and controlling bandwidth and storage subsystem resources. The embodiment describes controlling of resources belonging to a SAN subsystem. In a co-pending patent application bearing IBM Disclosure ARC9-2002-0010 entitled A Method for Improving Performance in a Computer Storage System by Regulating Resource Requests from Clients, the contents of which are hereby incorporated by reference herein, an invention is described that facilitates the controlled concurrent utilization of resources in a shared storage system.
In the system described in the invention, I/O requests are examined before and after they are serviced for monitoring resource usages and for regulating the different I/O streams to provide differentiated service.
The system provides performance guarantees to multiple I/O streams sharing the same storage system by controlling the rate at which requests from an I/O stream are issued to the back-end, thus regulating the amount of back-end resources being used by an I/O stream. The invention is not application-aware and any changes in application requirements have to be communicated to it explicitly. The invention also does not describe any mechanisms to distinguish different types of I/O tasks (e.g., OLTP request vs. backup request). Generic I/O tags could be used for this purpose, but it would be cumbersome solution.
For example, if a backup application runs for an hour everyday, an administrator will, have to explicitly configure the system to assign resources to the backup's I/O stream before the backup is taken. After the backup is taken, the administrator will have to reconfigure the system to revoke the resources assigned to the backup's I/O stream, The administrator could also assign resources to the backup permanently and not have the resources available to other applications even when the backup is not running.
Further, the aforementioned application does not describe how the I/O stream control mechanism can be used to allocate resources for multiple recurring backup tasks whose start times are variable but which need to complete within a certain time-window.
The system described above in IBM patent application disclosure ARC9-2002-0010 has a concept of service classes that can be used to provide some of the functionality provided by RMRS; e.g., the ability to distinguish among multiple clients. The notion of service classes is not sufficient for planning or reservation purposes, but it can be used to distinguish clients from one another. It is important to note that the same client can have multiple I/O tasks with different priorities (e.g. backup vs. recovery). It would be unrealistic to assume that all the tasks of higher class client are more important than all the tasks from lower class client; e.g. recovery task from a lower class client could be more important than backup task of a higher class client. RMRS facilitates such task level prioritization over to more static class based approach.
RMRS can function on top of any shared storage system, which allows monitoring and control of I/O streams based on the application requirements. The system described in the above mentioned patent application (i.e., IBM patent application disclosure ARC9-2002-0010) allows this kind of control to be available for networked storage systems like SAN and NAS. Thus, RMRS and the system described in IBM patent application disclosure ARC9-2002-0010 complement each other, and together they facilitate policy-based and application-oriented resource planning and allocation.